Method for signaling client rate capacity in multimedia streaming

ABSTRACT

A method for signaling and negotiation between a resource-limited client and a server in a multimedia streaming service regarding packet data delivery. In order to avoid dropping packets at the client side due to its maximum packet rate capability, the client signals to the server declaring the maximum packet rate capability. This capability can be signaled to the client via a capability exchange mechanism or using a multimedia streaming protocol. The client inserts a parameter indicative of the maximum packet data rate capability in a request sent to server. It is up to the server to take the necessary action and make the packet delivery rate adjustment.

[0001] This patent application is based on and claims priority to U.S.Provisional Applications No. 60/447,264, filed Feb. 13, 2003; No.60/448,309, filed Feb. 14, 2003; No. 60/448,284, filed Feb. 14, 2003 andNo. 60/448,299, filed Feb. 14, 2003.

CROSS REFERENCE TO RELATED PATENT APPLICATIONS

[0002] This patent application is related to U.S. Patent Applications,Docket No. 944-001.103-4, and Docket No. 944-001.103-5, both assigned tothe assignee of the present patent application and filed on even dateherewith.

FIELD OF THE INVENTION

[0003] The present invention relates generally to multimedia streamingand, more particularly, to signaling of client's packet rate capacity inmultimedia streaming sessions.

BACKGROUND OF THE INVENTION

[0004] In a multimedia streaming service, there are three participantsinvolved: a streaming server, a streaming client and an underlyingnetwork which provides the connectivity between the server and theclient. The server provides the functionality to deliver the multimediastreaming content to the client. For that purpose, the client and servercommunicate with each other over the network regarding the methods ofcapability exchange, content delivery method negotiation, contentdelivery control, and so forth. Such information exchange can be carriedout via well-defined network protocols.

[0005] For a multimedia streaming session to be set up and startedsuccessfully, the server and the client need to support a minimal set ofprotocols, which are selected as standard protocols by the service. Anexample of such a service can be found in 3GPP TS 26.234 V5.1.0,“Transparent End-to-End Packet Switched Streaming Service (PSS);Protocols and Codecs (Release 5)”, June 2002, hereafter referred to asTS 26.234). Examples of such a set of protocols used in 3G PSS are SDP(see, for example, IFTF TFC 2327: “SDP: Session Description Protocol”,Handley et al., April 1998), RTSP (see, for example, IETF RFC 2326:“Real Time Streaming Protocal (RTSP)”, Schulzrinne et al., April 1998)and RTP/RTCP (see, example, IETF RFC 1889: “RTP: A Transport Protocolfor Real-Time Applications”, Schulzrinne et al., January 1996).

[0006] In a streaming service, the client may be an application runningon a device that is resource-limited. It may be the case that the clientcould not handle more than a well-defined number of packets arriving toits receiving node.

[0007] In most of the services, the server and client negotiate on theavailable bandwidth to use for the content delivery. However, if theclient is a resource-limited device, then it also has a limitation onthe maximum number of packets that it can actually capture from itsreceiving node. Most of the time, this limitation is not signaled.

[0008] One particular case where this can be a problem is in audiostreaming, where there can be data delivery at a packet rate of 50packets/second (e.g., AMR-NB codec with 1 AMR-NB frame/payload). Ifthere are two audio media sources delivering data to the same client atthe same time (or in a different case when there is also a video sourcedelivering media packets at the packet rate of 50 packets/second, inaddition to the audio media source), there will be a 100 packets/secondpacket delivery rate, which can be too high for the client to handlewithout packet dropping.

[0009] Therefore, there is a certain need to negotiate this valuebetween the client and server to have a well-adapted session.

SUMMARY OF THE INVENTION

[0010] The present invention provides a method of signaling andnegotiation between a resource-limited client and a server in amultimedia streaming service regarding the data delivery from the serverto the client. In particular, the present invention provides a method ofsignaling the maximum packet rate capability of the client to the serverso that the server does not overrun this maximum packet rate value,causing packet drops at the client side or crashing the client mobiledevice. The method can be carried out using a capability exchangemechanism, or using a multimedia streaming control protocol.

[0011] Thus, the present invention provides a method for controllingstreaming data delivery in a multimedia streaming network having aserver for providing the streaming data to a client at a packet datarate. The method comprises:

[0012] declaring in a message a maximum data rate capability at theclient; and

[0013] signaling the message to the server.

[0014] According to the present invention, the message comprises arequest sent to the server via a capability exchange mechanism, and therequest comprises a capability profile for indicating the maximum datarate capability. The maximum data rate capability is indicated by acapability parameter in the capability profile, and the capabilityparameter is included in an RTSP DESCRIBE request.

[0015] Furthermore, the maximum data rate capability is indicated incapability information residing in a capability exchange server, andwherein the request includes a URL pointing to the capabilityinformation. The server, responding to the request, retrieves thecapability parameter from the capability exchange server via thecapability exchange mechanism for adjusting the packet data rate.

[0016] The server may adjust the packet data rate based on capabilityparameter in order to fit the maximum data rate capability at theclient.

[0017] Alternatively, the message is signaled to the server via amultimedia streaming control protocol, and the message comprises arequest including a RTSP header extension indicative of the maximum datarate capability.

BRIEF DESCRIPTION OF THE DRAWINGS

[0018]FIG. 1 shows a declaration by a client as part of the signalingand negotiation process, according to the present invention.

DETAILED DESCRIPTION OF THE INVENTION

[0019] The method of signaling and negotiation between a client and aserver in a multimedia streaming service regarding the adaptation of thedata delivery process, according to the present invention, can becarried out via a capability exchange mechanism or via a MultimediaStreaming Control Protocol. The Multimedia Streaming Control Protocol iswell-defined and standardized within the service context. The capabilityexchange mechanism is known in the art and, therefore, is not part ofthe present invention. The adaptation of the data delivery process isbased on the maximum packet rate capability of a resource-limitedclient. The client uses a MaxPacketRate value (packets/second) to definethe maximum amount of packets it can handle in a certain time interval.

[0020] When the signaling is carried out via a capability exchangemechanism, the procedure can be based on the standard as set forth in TS26.234, for example.

[0021] Let the attribute “MaxPacketRate” be defined in the RDF (ResourceDescription Framework) Schema vocabulary for signaling the value of themaximum packet handling rate capability of the client. The attribute isdefined in packets-per-second units.

[0022] The signaling procedure is as follows:

[0023] Client declares the MaxPacketRate value as a capability parameterin its capability profile. For example, the client sends an RTSPDESCRIBE request to the server with a URI pointing to the clientcapability information residing in a capability exchange server.

[0024] The server retrieves the capability declaration of the clientfrom the capability exchange server via the capability exchangemechanism. The declaration has the part for the client-side streamingcapabilities, as shown in FIG. 1. The bold lines in the declarationrepresent the maximum packet rate capability of the client. Havingobtaining the MaxPacketRate value, the server has the information aboutthe current packet rate to adjust the maximum packet reception ratecapability of the client. The server can then adjust the maximum packetrate delivered to the client. However, it is up to the server to takethe necessary action and make the packet delivery related adjustments.

[0025] When the signaling is carried out via a Multimedia StreamingControl Protocol, the client can use the well-defined RTSP option tag,and the RTSP header extension (see, for example, IETF RFC 2326).

[0026] Let “x-maxpacketratesupport” be an RTSP option-tag.

[0027] Let “x-maxpacketrate” be an RTSP header extension defined inpackets-per-second units.

[0028] The client is assumed to know the RTSP URL (universal resourcelocator) for the multimedia session beforehand.

[0029] The signaling procedure is as follows:

[0030] Client declares the MaxPacketRate value in a DESCRIBE requestsent with the x-maxpacketrate value signaled:

[0031] Client→Server:

[0032] DESCRIBE rtsp://foo/twister RTSP/1.0

[0033] CSeq: 1

[0034] Require: x-maxpacketratesupport

[0035] x-maxpacketrate: 70

[0036] If the server does not make use of the maximum packet ratecapability of the client, server responds either with an RTSP 551“Option Not Supported” message containing the “Unsupported:x-maxpacketrate” line, or with an RTSP 200 OK message containing the“Unsupported: x-maxpacketrate” line. By the usage of RTSP “Require”header, the client understands whether the server takes the parameterinto account or not. If the server takes the parameter into account, theclient can signal the updated maximum packet rate capability during thesession, using any RTSP message body.

[0037] If the server makes use of this parameter, the server checks theRTSP request and sees that it contains the well-defined x-maxpacketratevalue. It retrieves the value from the RTSP request message.

[0038] After knowing the MaxMacketRate value in requests sent by theclient, the server uses the value to adjust the maximum packet ratedelivered to the client. However, it is up to the server to take thenecessary action and make the packet delivery related adjustments.

[0039] It should be noted that the maximum input packet rate coming froma network interface, which is sustainable by the client device can bedefined as MaxPacketRate in the RDF Schema vocabulary, but it can becalled differently. Likewise, “x-maxpacketrate” or a different name canbe used in an RTSP message, so long as it can be used to specify themaximum input packet rate coming from the network interface, which issustainable by the client device. “x-maxpacketratesupport” or adifferent name can be used in an RTSP “Require” header, so long as itcan be used to specify the capability of the server to understand andtake into account the maximum input packet rate header transmitted inany RTSP message body sent by the client device.

What is claimed is:
 1. A method of controlling streaming data deliveryin a multimedia streaming network having a server for providing thestreaming data to a client at a packet data rate, said methodcomprising: declaring in a message a maximum data rate capability at theclient; and signaling the message to the server.
 2. The method of claim1, wherein the message comprises a request sent to the server via acapability exchange mechanism, and the request comprises a capabilityprofile for indicating the maximum data rate capability.
 3. The methodof claim 2, wherein the maximum data rate capability is indicated by acapability parameter in the capability profile.
 4. The method of claim3, wherein the capability parameter is included in an RTSP DESCRIBErequest.
 5. The method of claim 4, wherein the maximum data ratecapability is indicated in capability information residing in acapability exchange server, and wherein the request includes a URLpointing to the capability information.
 6. The method of claim 5,wherein the server, responding to the request, retrieves the capabilityparameter from the capability exchange server via the capabilityexchange mechanism for adjusting the packet data rate.
 7. The method ofclaim 6, further comprising the server adjusts the packet data ratebased on capability parameter in order to conform to the maximum datarate capability at the client.
 8. The method of claim 1, wherein themessage is signaled to the server via a multimedia streaming controlprotocol.
 9. The method of claim 9, wherein the message comprises arequest including a RTSP header extension indicative of the maximum datarate capability.